AWS Cloud Storage Day 取材レポート(5).[A-02] 東急ハンズが実践するファイルサーバのクラウド化。企画、実現方法から、実際の性能まで。

AWS Cloud Storage Day取材レポート

#イベントレポート

#勉強会

#レポート

#AWS Storage Gateway (S3 File Gateway)

#AWS

しんや

2013.09.25

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

講師・概要紹介

講師

松尾康博氏 (アマゾンデータサービスジャパン株式会社ソリューションアーキテクト)
今井智明氏 (ハンズラボ株式会社 ITエンジニア)

概要

東急ハンズ様は、2012年10月に全てのサーバーをAWSへという決断をして以来、サーバーの新規購入を凍結しAWSへの移行を進めています。ファイルサーバーも2013年3月にAWSへ移行し、運用を開始しました。本セッションでは、アーキテクチャ、移行方法、運用開始後の評価、について紹介します。

セッション内容レポート(松尾康博氏)

クラウドストレージサービスの概要

現在、クラウドストレージが求められる背景としては、オフサイトバックアップやデータミラーリング、クラウドファイルサーバとしての要望が挙げられます。最終的にはクラウドで完結してしまおう、という狙いです。また、一方で、この要望の実現に立ちはだかる課題というものも存在します。事前に十分な容量を見積もる必要が有る(実際クラウドだどどうなのか？)、確実なバックアップや容易なリストアが必要とされる(笑えない冗談のような自体も多く目のあたりにしてきました。そのような状況をなるべく回避し、作業を簡単に行いたい)等。また、性能を満たしているかという点も重要です。

(写真：松尾康博氏)

AWSの様々なサービスの中で『ストレージサービス』と言うと、以下のサービスが挙げられるかと思います。

Amazon S3
Glacier
Storage Gateway
EBS

今日は、その中でStorage Gatewayについて解説して行きます。

Storage Gatewayのご紹介

Storage Gatewayとは、オンプレミス環境とS3を連携したデータバックアップ及びクラウドストレージサービスです。Storage Gatewayは仮想アプライアンスとして動作します。サポートするプラットフォームはVMWare ESXi、Hyper-V、EC2等です。基盤に乗せて頂き、ISCSIと繋ぐ事で、オンプレミス環境からはファイルサーバとして見え(しかし実情はStorage Gateway)、ローカルに書き込みを行いつつ、S3にもバックアップが取られる、と言う仕組みです。

仮想アプライアンス（かそうアプライアンス、英: Virtual appliance）は、Parallels、VMware、Xen、Microsoft Virtual PC、QEMU、User Mode Linux、CoLinux、Virtual Iron、VirtualBoxといった仮想化技術の上で動作するよう設計された最小仮想機械イメージである。
仮想アプライアンス - Wikipedia

AWS Storage Gatewayには2つのタイプが存在します。Gateway-Stored VolumesとGateway-Cached Volumesです。

Gateway-Stored Volumes: Gateway-Stored Volumesは、オンプレミス環境のボリュームをAmazon S3に自動複製します。1ボリューム1GB〜1TBまで指定可能、1つのGatewayで最大12個のボリューム(＝最大12TB)を作成可能です。ボリューム単位で、S3上にEBS Snapshot形式での保存を行います。
Gateway-Cached Volumes: Gateway-Cached Volumesは、Storage Gateway経由でAmazon S3を直接利用する事で、堅牢性の高い大容量ストレージを実現します。1ボリューム1GB〜32TBまで指定可能、1つのGatewayで最大20個、合計150TBまでボリューム作成が可能です。S3そのものをストレージとして使うため、遅いです。なので、キャッシュを用意し、性能を犠牲にする事無く実現しています。

Storage Gatewayを利用したモデルとして、『クラウドファイルサーバ』があります。ご覧のように、以下3つのネットワーク構成パターンにより、クラウドファイルサーバとしての機能を実現出来ます。(下記写真参照)

AWS Storage Gatewayの詳細

セキュリティと運用という面から、AWS Storage Gatewayを解説して行きましょう。

セキュリティへの配慮: AWSと各Gateway間のデータは、全てSSLで暗号化されてデータ転送されます。また、クラウド側のデータはAES-256を用いて暗号化されます。
自動アップデート: Storage Gatewayはアップデートやパッチを自動的にダウンロードし、適用します。また、パッチ適用の時間帯を指定する事も出来ます。
スナップショット: ボリューム単位のスナップショットを自動で取得・保存可能です。(任意取得も可能です)。スナップショットはS3に保存されます。

性能監視という点では、Amazon CloudWatchを利用した環境・性能監視が可能です。

クライアントとGateway間のパフォーマンス測定
GatewayとAWS間のパフォーマンス測定
ストレージ関連のパフォーマンス、空き容量
キャッシュヒット率等

以上、Storage Gatewayに関する解説でした。Storage Gatewayを利用する事でオンプレミスとクラウドをシームレスに接続し、高い耐久性のファイルサーバを従量課金で構築し、利用して行く事が出来ます。是非、ご利用を御検討頂ければと思います。ありがとうございました。

セッション内容レポート(今井智明氏)

ファイルサーバのクラウド化の背景

まずは移行前のオンプレミスの構成についてご説明します。(以下写真参照) サーバを本社・店舗・個人で分け、対応したバックアップサーバも用意しました。バックアップは週次・日次でそれぞれ行っています。

ファイルサーバについては、以下の様な悩みを抱えておりました。

容量が足りない: ディスク使用率が常に100%近い状態にありました。ある程度の容量を見込んでいたのですが、甘かったです。データは来年度使うかも知れないので消せないし、いずれ使うかもしれないので取っておきたいという思いはありました。
バックアップへの不安がある: 週次のフルバックアップに5日間掛かるような状態でした。バックアップソリューションとして、バックアップの間レストアが出来ない、という問題も抱えていました。
事業継続性: 3.11を目の当たりにして、このテーマについて考える必要性に直面しました。データセンターに万一の事があると…と考えると単一拠点では不安です。

ディスク容量やリプレースも検討しましたが、予算等を考慮すると到底賄い切れない状況にはありました。そんな時、頼りになったのが、Storage Gatewayと松尾さんでした。(ﾁﾗｯ

容量の問題については、1つのStorage Gateway当たり150TBまでボリュームを作成出来、少なめにボリュームを見積もっても後から拡張出来ました。バックアップの問題については、S3のスナップショット機能で高速バックアップが行え、差分バックアップで費用も抑える事が出来ました。また、事業拡張性についても、ボリュームのデータはS3に(複数のDCに分散し、イレブンナインの耐久性を以って)保存される為、要件を満たせました。

クラウド化の手順と方法

Storage Gatewayへの移行手順としてましては、まずはリスクの少ないところから移行を始めました。業務への影響が少ない個人ドライブ(個人所有のドキュメントなど)を選択しました。Storage Gateway構築に際しては、管理コンソールから簡単に構築が行えました。まずEC2インスタンスを立ち上げ、ボリュームは8TB、バッファやキャッシュもとりあえず100GBずつ確保して始めています。あとは実データを移行し、バリバリ使って検証して行きました。やはり実際に使ってみないと分からない部分は多いです。業務で使えるパフォーマンスが出るかどうか、業務で発生するリカバリに対応出来るか、と言った視点で検証を行いました。

Storage Gatewayの移行方法については、ひたすらXCOPYで行いました。どなたか、いい方法があったら教えて頂ければと思います。ネットワーク越しでは時間がかかるため、切り替えに業務への影響が少なくなるよう何回も回しつつ差分を減らしたり、細かくディレクトリを指定する等の工夫も行いました。

Storage Gateway移行時にはハプニングもありました。本番機のWindows2008にiSCCIイニシエータを入れたところ、再起動ループに嵌ってしまいました。本社ドライブが使えなくなる事態に陥り、結果としてはセキュアモードでアンインストールを行い何とか復旧はさせたものの、教訓として環境はケチってはならないという事を学びました。

(写真：今井智明氏)

Storage Gatewayの検証については、以下の様な結果となりました。

バックアップとレストアに関してはスナップショットから簡単に復旧出来ました。8TBでおおよそ2〜3分で作成が行えています。
パフォーマンスに関しては、読み書き共にオンプレミスとほぼ変わらずの速度感でした。Direct Connectがあれば気にならない範囲であり、読み書きはキャッシュヒットすれば十分速いのでは、と思います。
障害シミュレーションに関しては、再起動しても、作り直しても問題無し。別途Storage Gatewayを作成し、スナップショットからボリュームを作って繋げても大丈夫でした。

また、移行した結果や感想としては、以下のようなポイントを挙げたいと思います。

十分な安定性とパフォーマンスを持ち、問題無く稼働していると感じました。ディスクをベーシックにしてからは一度も落ちていません。
ファイルが確実に戻せるという安心感はあります。Windowsのシャドウバックアップとの組み合わせが個人的には良いのでは、と思います。
費用感については、トータルではオンプレミスより高く無いのでは、と思います。インスタンスやストレージ使用料だけ見ると高く感じますが、高信頼性、高拡張性、運用コストの最小化等、トータルで見れば決してそんな事は無いと思います。

今後の予定とAWSへのリクエスト

今後は本社や店舗用のデータも、継続して移行していく方向です。

そして、AWS様にも今回の件を通じて幾つかリクエストしていきたいと思います。

マネージメントコンソールの機能を強化して欲しい。特にStorage Gatewayはもっと使い易く出来ると思います。スナップショットの検索や一覧からのボリューム作成等も出来るようになると嬉しいです。
Storage Gatewayの自動連携機能。長期間アクセスされていないファイルをGlacierに行くようにし、より安価にして欲しいです。
Dropboxライクなマネージドファイルサーバサービスが欲しい。Webを基本とした、各OSのGUIとシームレスな連携が出来るようにして欲しいです。

以上、私からの発表を終わります。ご清聴ありがとうございました。